Revert claude-review to the pull_request trigger - #89

Working on this --- paws off until I'm done.

Both claude-review results are expected, and neither is a review

Read the logs rather than the colors --- the green one is a skip, not a review:

Skipping action due to workflow validation: Workflow validation failed.
The workflow file must exist and have identical content to the version on
the repository's default branch.

That is the documented behavior for a PR that edits the review workflow, and the action exits 0 on it.

The point is where each run stopped. The pull_request run's OIDC token was accepted and it got as far as workflow validation; the pull_request_target run, in the same repo, in the same minute, on the same secret, was rejected outright at 401 Invalid OIDC token. That is the cleanest available demonstration of the cause, since the only variable between them is the trigger event.

The red check is main's current workflow reviewing this PR. It cannot go green before merge, and it stops firing once this lands. main is unprotected, so it does not block.

No external verdict is obtainable at this head, so I have requested Copilot review and will self-review in the meantime.

Ready for merge

Copilot reviewed the current head (4160c10) at 02:36Z and returned no findings --- its overview describes all three changes correctly. Zero inline threads, no CHANGES_REQUESTED.

Checks:

That last one is red by design, not oversight: it is main's current broken workflow reviewing the PR that fixes it, and no change to this branch can turn it green. It stops firing the moment this merges. main is unprotected, so it does not block.

claude-review did not produce a verdict at this head for the skip reason, so the clean call rests on Copilot's review alone. A genuine end-to-end review is first observable on the next PR opened after this merges --- worth watching, since that is the real confirmation.

Not merging --- that is yours to call.

Correction: this repo does have a fork PR

The body's "Fork PRs" section claimed none had ever been opened here. That is false --- #77 (imelainew/ucd-serg.github.io) has been open since 2026-06-30. I read main in the branch column as a same-repo branch instead of checking head.repo.fork. The section is rewritten in place and marked as corrected, since the original is what Copilot's review read.

A second claim in #88 was wrong the same way: I described run 30663424918 as "missing id-token: write". That is #77's run, the workflow does grant it, and GitHub withholds it from fork PRs regardless. The run's own error text guesses at the misconfiguration I then repeated.

The revert still stands, on a corrected argument. pull_request_target was not trading fork coverage for anything --- the exchange 401s on every PR, forks included, and a working exchange would still refuse an outside contributor without allowed_non_write_users. Fork PRs are unreviewed today and stay unreviewed after this merges, which is now tracked as #90 rather than dismissed in a PR body.

Nothing in the diff changes. Re-requesting review since the description Copilot reviewed no longer matches.

Copilot re-reviewed at 02:52Z against the corrected description: "reviewed 1 out of 1 changed files and generated no new comments." Two clean reviews now, zero inline comments, and the diff is unchanged from the first one. Still ready; still yours to merge.

Correction, post-merge: one claim in this PR was false, and #91 is fixing its consequence.

I wrote that reducing pull-requests from write to read was safe because "the action posts with its own app token, so the workflow token does not need write." That is wrong. The app token covers the action's own bookkeeping; the review is posted by Claude's tool calls under GITHUB_TOKEN, so read denies them --- permission_denials_count: 8 in run 30681158599 on #87, with the check still green.

I also called this diff "byte-identical to the last version that produced successful reviews." Byte-identical, yes. Producing reviews, no: claude has never posted a review comment on this repo. #78, #79, #80, and #86 all ran green with zero, and git log -L shows pull-requests: read present since the workflow's first commit.

So the trigger fix here was right and the permissions change rode along on an untested premise. Both facts held at once and the second was invisible, because a green check is what a silently-dropped review looks like --- the same reading failure this PR's own description warns about for the workflow-validation skip, one line lower in the same file.

Fixed forward in #91 rather than by reopening this. Evidence posted there.